Distributed computer environments, such as computer networks, provide significant advantages to multiple computer clients or users. In particular, distributed environments allow multiple clients to actually share many different computer resources including both hardware and software resources. Sharing software-related resources provides many known benefits, such as the fact that only one such resource needs to be created, updated and maintained.
The Internet is one particular example of a distributed environment that provides access to a considerable number of software resources, which are available to client computer systems having Internet capabilities. One portion of the Internet is known as the World Wide Web which is generally a system of Internet servers that house software related resources that are formatted in a particular manner, such as with HTML (HyperText Markup Language). The protocol for accessing these particular resources is known as the HyperText Transfer Protocol or HTTP. It should be noted however that not all Internet servers are part of the World Wide Web.
Historically, most resources on the Internet corresponded to web page files that included only static HTML code, and thus were only available for display. However, recent advances are being made in the representative functionality provided to client systems to provide more interaction between the client and server systems. For instance, clients may effectively author resources on a server system from client systems over distributed networks, including the Internet. Indeed, much time and effort has been spent on the development of a WebDAV protocol or standard, which stands for the World Wide Web Distributed Authoring and Versioning standard, referred to herein as simply “DAV.” DAV provides a set of headers and methods which extend HTTP to provide capabilities for managing properties, namespace and other items from a client system in order to allow client computer systems to access server-side resources for the purpose of editing those resources. Proposed Standard RFC 2518, which is a document written by the IETF and approved by the IESG, published February 1999, describes DAV in more detail.
As part of the DAV standard, server computer systems provide various services in managing the various access requests made by clients. One particular service relates to managing resource availability for clients. That is, DAV provides methods that allow a client to lock a resource when using that resource so that subsequent users may not access that resource during that time. This locking scheme helps prevent the “lost update” problem associated with two or more users modifying a resource simultaneously such that editions are inadvertently lost.
Unfortunately however, the DAV protocol is limited in its ability to satisfactorily allocate previously locked resources to requesting clients. That is, once a resource is unlocked, then the server computer system simply allocates the resource to the next client that sends a request for that resource. While relatively simple, the method of allocating the resource to the next request is unsatisfactory as it forces clients to repeatedly and almost continuously request a locked resource. Repeated requesting of a resource by a client significantly impacts the performance of the client computer system because the client computer system must devote its own resources to preparing and sending a request while these resources could be performing other tasks.
In order to improve performance, the client computer systems typically employ a method of choosing a predetermined time interval between requests for locked resources. Unfortunately however, choosing a time interval that is too long may jeopardize the chances of accessing a resource as an intervening request by a different client may occur between the time of the unlock event and the next request. Indeed, since an intervening request may always appear prior to any other request, any particular client may suffer from lock starvation, i.e., a complete failure to gain access to a requested resource. Therefore, choosing a time interval necessarily requires the client to balance performance issues with the importance of accessing the resource. Achieving a satisfactory balance is difficult at best, and such guesswork cannot guarantee that a resource will ever be accessed, based on other client request rates.
One method of solving this problem relates to evaluating an existing lock using a “lock discovery” method that evaluates an existing lock to determine properties such as whether a timeout period has been set. In DAV, the timeout period for a resource is a values set by the owner or the server system and provides a means by which the server can limit the lifetime of a resource lock. Upon expiration of the timeout period, the server may harvest the lock and reallocate the resource to the next client that requests the resource. By discovering the timeout period, a client may wait until that period has expired before sending another request for the resource. Unfortunately however, this solution is unsatisfactory since the lock creator typically chooses a timeout period that far outlasts the actual time needed for the resource. Indeed, since the nature of a requested timeout period relates to when the lock expires or may be harvested by the server, clients typically choose as long a period as possible. If not, the lock owner risks having a lock expire before the owner is finished with the resource. Consequently, subsequent clients cannot rely on the timeout period as a means for realistically determining when to retry a request.
Another drawback associated with the timeout period used in DAV, i.e., the time period by which the lock automatically expires, is that the timeout period may actually be set for an infinite duration. This causes a significant problem, especially when the client does not explicitly release or unlock the resource when the client does not need the lock any longer. The problem is exacerbated when the client owning the lock orphans the lock and thus cannot explicitly release the resource. In such a case, there is essentially no method of killing or breaking the lock.
It is with respect to these and other considerations that the present invention has been made.